Preparing for the SAP Sizing Process

I like to have the project’s SAP solution architect take ownership of completing all questionnaires. The SA is also well-equipped to actually answer most of the questions, so this approach makes sense, with the following exceptions:

• Disk sizing questions that derive their questions from functional or transaction-based requirements can actually be better addressed by experienced end users (super users), especially when they are paired with experienced SAP basis or sizing experts.

• The SAP project manager should provide an SAP resource trained and experienced in sizing. SAP often refers to this skillset as capacity planning. Regardless of the label, this role is critical from a quality assurance point of view.

• A member of each hardware and software vendor’s technical sales staff should also be involved, responsible in a liaison-like manner for ensuring that the customer-vendor SAP sizing process does not stall. Because of the iterative nature of good sizing, the process is especially susceptible to being derailed over time; direct involvement of each vendor helps avoid this.

After the questionnaire, RFI, and/or output data from the SAP Quick Sizer is internally reviewed, refined, and shared with your prospective vendors, it’s a good idea to host a one- or two-hour conference call with everyone. I have seen calls hosted by a customer where all potential vendors were on the call, and at the other extreme I have played a part in one-on-one calls, too. Either way is effective, but for the sake of apples-to-apples comparisons, I prefer that a single conference call be used to host everyone—this way, everyone hears the same things. I also suggest that the senior solution architect as well as both the client and SAP project managers host the call, as then most any question can be answered “real-time.”

The Pre-Sizing Conference Call in the Real World

Through this initial pre-sizing conference call, before any real hardware sizing begins, you can accomplish a lot. First of all, you can help set the stage for your particular mySAP project by sharing your vision, your business drivers, and your timelines. You also have an opportunity to outline your priorities, discuss your biases, identify the skillsets and experience you already have in-house that will prove relevant to managing and supporting SAP, and so on. All of this will serve to greatly improve your chances of obtaining SAP solution sizings that are done as close to “right” as possible, the first time.

Remember, of course, that the sizing process is still iterative even in the best of worlds. However, the conference call approach just discussed will minimize the number of unnecessary and time-consuming SAP solution resizings that you would otherwise be forced to review.

Given all of the sizing conference calls and onsite meetings that I have attended personally, I thought it would make sense and be in your best interests to share the kinds of questions and data that I most often appreciated—my solution sizing colleagues with whom you will work will certainly appreciate much of the same:

• As I mentioned previously, take this time to set the stage for your particular mySAP project in terms of Solution Vision, SAP components to be implemented, business drivers, project timelines, key milestones, and other project-specific data.

• Determine whether this new SAP component to be sized is being integrated with an existing SAP landscape, replacing a current system, or simply refreshing a current system. If vendors have little direction in this regard, then the resulting sizings will probably be so different as to be incomparable.

• Review the numbers you have shared through your RFI, Sizing Questionnaires, or Quick Sizer output, and make sure that everyone understands your definition of what the term “user” means to you.

• Clearly identify your priorities in regard to the following—total cost of ownership, performance, availability, scalability, and manageability. Giving your hardware vendors this kind of insight helps to avoid huge surprises when you finally receive their version of what you need in terms of an SAP solution sizing.

• Discuss your system architecture and other technology biases, including whether you prefer a central system approach to a more distributed architecture, whether you are biased for or against a particular operating system or database product, and so on. You should also share what hardware, OS, and database platforms your current enterprise software solutions depend upon.

• Along these same lines, be sure to share the skillsets and experience you already have in-house with regard to various hardware, OS, and database platforms, and how likely you are to change or accept something new.

• Discuss your views and thoughts with regard to risk: Are you willing to try something brand new, or reasonably new, if the potential rewards are great? Do you tend to favor a conservative approach to solution sizing, or something perhaps more innovative or leading-edge?

• Identify which SAP system landscape components must absolutely be sized (like development, test, and production), and which might be “in the air” (like a business sandbox, technical sandbox, training system, and so on). Include whether you prefer the same platforms and components across these systems (a high level of standardization), or whether initial budget constraints require a different approach. The more details the better.

• Similarly, address the sizing of each database for each system landscape component.

• If scalability was not previously covered in detail, indicate something as to the scalability that the system must provide. For example, does your company intend to grow or shrink significantly through acquisitions, mergers, or divestitures over the next 12–36 months?

• In terms of accessibility and front-end desktop or laptop requirements, will Internet access be required? What about new desktops or other client devices?

• If certain vendors have already been selected, I think it makes sense to share this information as well. For example, as a hardware vendor with excellent relationships with a number of the “Big 4,” I like to hear about whether an SAP consulting organization has already been selected to do the functional work of implementation. Similarly, it’s helpful to understand which systems integrators, if any, have already been selected, or whether a certain database or operating system vendor has already been given the nod.

• You also need to discuss any plans for stress-testing, and any thoughts you might have on proof-of-concept exercises. Every now and then, at little to no cost, you can leverage an SAP technology partner to actually “prove” that his solution operates as advertised. This is more often the case with new SAP Solution Stack alternatives that a particular technology partner is anxious to “get into production” for the sake of selling more of the same solutions down the road. In example, I’ve been involved with POCs related to proving the scalability of new hardware platforms and different database products.

• Open up the call at this point for questions. Usually, questions involve clarifying why or how you completed the questions in various SAP sizing questionnaires, or clarification of data provided in your RFI.

• I believe that it makes sense to end the call with a synopsis of everything that has been discussed, and a specific date by which you expect all solution sizings in your inbox, along with reiterating what you perceive to be the greatest risk in your SAP project plan. This latter point serves to remind all of the participants on the call how important your SAP project is to your business, and therefore should underscore the importance that each vendor places in his solution sizing efforts. Follow up these words with a written one to two page document shared via email.

With a solid sizing foundation produced, you can now let your prospective hardware and software partners get to work crafting solutions that not only meet your business requirements, but hopefully also reflect each partner’s unique hardware capabilities and competitive advantages.

Building Your Sizing Evaluation Team

With sizings in process, it’s time to get started assembling an official Sizing Evaluation Team (SET). Up to this point, the solution architect and some of his senior team members have played a role in working to develop, document, and otherwise publish your system requirements. Your Knowledge Repository has served its purpose, too, and will continue to grow in value as the solution sizings start rolling in. Additional SAP Technical Support Organization (SAP TSO) team members need to be pulled in at this point, however, to build a virtual team or subteam that includes the following staff:

• The senior solution architect heads this team. Other solution architects may be needed to help evaluate solution sizings and work with different technology partners, however. This is because a large SAP project covering four or five mySAP components, shared with four or five different SAP technology partners, can add up to a whole lot of reading for a single SA to do.

• Technology SMEs (Subject Matter Experts) in each solution stack layer must be represented on the team, including data center, hardware, network, OS, database, and of course mySAP specialists. This often includes many preselected technology partners (SAP and perhaps hardware and database experts). Even so, do your best to avoid obviously biased team members; an open mind is important at this stage in the project. Together, the senior solution architect, any other solution architects, and the combined SMEs make up the core of the SET team.

• Current systems administrators, systems management, and computer operations organizations are represented. This is more for their benefit than the core SET team, but helps to build excellent relationship bridges as well.

• Business staff (from key functional areas) must be represented, to include them in the sizing review process and therefore develop critical buy-in. This avoids “I told you so” or “I didn’t know” later in the project, if something goes wrong.

• A documentation specialist (DS) will update your Knowledge Repository and play a role in developing or customizing evaluation templates or similar approaches, if, for example, the number of technology partners makes this necessary.

The goal of the SET team is simple: to review each solution sizing, and evaluate the responses in terms of each vendor’s ability to meet your needs. The team needs to keep the various project managers up to speed about this review process. None of this is trivial, though, as you see in the next section.

The Sizing Review Process

With each vendor’s sizing attempts in front of us, it is now time to review each solution document in terms of the following:

• Type of sizing—Is the sizing little more than a parts list, or a full-fledged solution architecture document, or something in between?

• Completeness—Does the sizing take into account the entire mySAP system landscape discussed in the pre-sizing conference call, or identified in the questionnaire?

• Reflection of the Sizing Questionnaire or RFI data provided—Does the sizing document clearly restate where it obtained its assumptions, boundary conditions, system requirements, biases, and so on?

• Accurate load factors—Are the correct named, online, or concurrent user counts reflected in the sizing, or is the proper transaction load noted? What about reporting and batch loads, or the potential impact due to expected heavy customizing?

• HA/DR—Is there a section in the sizing that addresses high availability and/or disaster recovery, as requested? Further, is the approach hardware-, OS-, or database-specific?

• Core infrastructure—Is there a section in the sizing that addresses core infrastructure requirements, including network, rack, special servers, systems management options, and more?

• Disk details—Does the sizing go into detail with regard to the disk subsystem configuration?

• Backup/Restore—Does the sizing address technology used to actually back up the various database structures and other file partitions that support your mySAP solution as architected by the vendor?

The Documentation Specialist (DS) has some work to do, then. An enterprising DS will not only insert all sizings and supporting data into the Knowledge Repository, but at the direction of the SA he will also begin identifying where and how solutions differ from one another. To do this effectively, a matrix is useful. For example, all assumptions, boundary conditions, and other constraints that are documented by each solution vendor need to be recorded between the individual sizings. Basic hardware configurations need to be verified as well, like the number and speed of CPUs, RAM, and disk drives in each server, the number of servers in each SAP system, the size and scope of each SAP system landscape, and so on. Further, missing components need to be noted, like the absence of Requisite BugsEye servers in mySAP SRM solutions, or overlooking the need for ITS servers. All of these factors and more influence the configuration, and therefore impact both the resulting parts lists and the price of each competing solution.

With the general review behind us, we can now begin to focus on evaluating each sizing with a critical eye when it comes to different layers in the SAP Solution Stack.